2012-09-08 - 4580 - Spec - Logistics Enhancement - Carrier Determination #Shipping

SPECIFICATIONS

Table of Contents

SPECIFICATIONS
4580 - Carrier Determination
Purpose
Admin Info
References
Prior Tickets
Documents
Functional Requirement
Solution Summary
Test Plan
Test Cases - ZTable and Delivery User Exit (incl Header Text Deletion)
Test Cases - Change Logs
Test Cases - Update fields (INCO1 and KVGR2) in SOs after creation of delivery.
Solution Details
Issues

4580 - Carrier Determination

Purpose

Enhance Logistic functionality to automatically determine Carrier and Incoterms based on weight based deliveries.

Admin Info

Title
 4580 – Carrier Determination
Requested By
 Robin Hahn
Spec Created By
 Thi Tran
Spec Created Date
 09-18-2012
Spec QA by
 Thi Tran
Objects
 ZSD_DELIVERY_DEL_TEXT
MV50AFZ1
ZSDT_CARR_DETR
ZCARRIER
Status
(WIP/Complete)
 Complete

References

Prior Tickets

None

Documents

Carrier Tests.xlsx


Functional Requirement

Currently, the carrier details are stored in the Customer Group 2 of the Customer Master and carried over to the Sales Order, Delivery and Billing Documents to determine Carrier details. When a customer has routing guides, a default carrier cannot be stored in the customer master because the carrier determination might be based on a number of different variables, like weight, transportation zone and/or number of units. In these cases, the Sales Order is placed on Delivery Block and manually removed and carrier details are updated when a Delivery is created and ready to ship.
Customers with routing guides are placed on Delivery Block and Logistics resources manually remove the block, update the incoterms and ship via (carrier) on the Sales Order when the Delivery is ready to be shipped.
To reduce all this manual intervention, we want to implement a solution that will update the incoterms and ship via (carrier) at Delivery creation, based on a set of criteria that will be maintained in a customer table.



Solution Summary

Discuss this section with Requester and get approval prior to beginning work
The solution will involve a number of enhancements:

1. Custom Table – Create a table that will be used to determine carrier and incoterms based on sold-to party, weight and shipping point. A proposed table is displayed below:
Field Name
 Key
 Data Element
 Domain
 Data Type
 Length
 Decimal
 Short Description
 Check Table
MANDT
MANDT
 MANDT
 CLNT
 3
 0
 Client
 T000
KUNAG
 X
 KUNAG
 KUNNR
 CHAR
 10
 0
 Sold-To Party
 KNA1
VSTEL
 X
 VSTEL
 VSTEL
 CHAR
 4
 0
 Shipping point
 TVST
MNGEW
 X
 MNGEW
 MENG15
 CHAR
 11
 3
 Minimum Weight
MXGEW
 X
 MXGEW
 MENG15
 CHAR
 11
 3
 Maximum Weight
GEWEI
 X
 GEWEI
 MEINS
 UNIT
 3
 0
 UOM
 T006
INCO1
INCO1
 INCO1
 CHAR
 3
 0
 Incoterms (Part 1)
 TINC
KVGR2
KVGR2
 KVGR2
 CHAR
 3
 0
 Customer Group 2
 TVV2
HDRTX
HDRTX
 HDTX
 CHAR
 1
 0
 Delete Account Header Text Indicator
2. Carrier Determination Table Maintenance – Create a transaction that will allow Logistics to maintain the records in the custom table. The transaction should be called ZSD_CARRIER.
3. Delivery Create User Exit – Enhance the Delivery creation user exit that will determine carrier, incoterms and what to do with the carrier details from the header text, based on the following logic:
a. If a delivery meets the parameters of a record in the table, create the delivery using the incoterms and carrier defined in the table.
b. If a delivery does not meet the parameters of any records in the table, but a record for the sold-to party does exist, use incoterms ROU and carrier 157.
c. If a delivery does not meet the parameters and there is no record for the sold-to party in the table, create the delivery. The incoterms and carrier from the Sales Order will automatically carry over to the Delivery document.
Here are some sample table entries and how the logic would work based on the custom table and customer master entries.
4. Change logs to be activated on the table to track data creation/changes.

Sample Custom Table records
MANDT
 KUNAG
 VSTEL
 MNGEW
 MXGEW
 GEWEI
 INCO1
 KVGR2
 HDRTX
100
 1000001
 0116
 0
 100
 LBS
 NEP
 UPSGD
100
 1000001
 0116
 100
 500
 LBS
 NEP
 FEDEX
100
 1000001
 9010
 0
 999999999
 LBS
 PPI
 ROU
 X
100
 1000002
 9010
 0
 500
 LBS
 FOB
 UPSAIR
100
 1000002
 9010
 500
 1000
 LBS
 CBC
 CALL
Sample Customer Master records
Sold-To Party
 Incoterms
 Customer Group 2
1000001
 ROU
 157
1000002
 NEP
 FEDGD
1000003
 PPI
 UPSGD

Test Plan

List test scenarios/cases to be executed here

Test Cases - ZTable and Delivery User Exit (incl Header Text Deletion)

Test Scenario
 Expected Results
Check custom table creation
 SAP table should match the table specified above
Go to transaction ZSD_CARRIER
 User should be brought to the custom table maintenance transaction
Add table entry
 User is able to add an entry to the table and save
Delete table entry
 User is able to delete an entry from the table and save
Copy table entry
 User is able to copy and change an entry from the table and save
Enter duplicate entry
 User is not able to enter a table entry that already exists
Enter values outside list of check tables
 User should not be able to enter values that aren’t in the check table
Create a delivery for a customer that has matching criteria to the table
 Delivery is created with incoterms and carrier changed to match the values from the table
Create a delivery for a customer that exists in the table but doesn’t have matching criteria
 Delivery is created with incoterms ROU and carrier 157
Create a delivery for a customer that doesn’t have any matching criteria to the table
 Delivery is created with incoterms and carrier defaulted from the Sales Order
Create a delivery for a customer that has matching criteria to the table and HDRTX indicator is checked
 Delivery is created with incoterms and carrier changed to match the values from the table and the header text is blank
Create a delivery for a customer that has matching criteria to the table and HDRTX indicator is not checked
 Delivery is created with incoterms and carrier changed to match the values from the table and the header text is carried over from the Sale Order
Create a delivery with UOM in Kg and table entry in lbs.
 Conversion should work correctly, choosing the correct weight range table entry
Create a delivery with UOM in oz. and table entry in lbs.
 Conversion should work correctly, choosing the correct weight range table entry
Create a delivery with UOM in lbs. and table entry in Kg.
 Conversion should work correctly, choosing the correct weight range table entry; first record should be picked if more than one matching weight range exits.
Create a delivery for customer 1000018 (entry exists in Ztable) and plant 1410 (entry doesn’t exist in Ztable for this customer)
 The incoterms and customer gr2 fields should be updated to ROU and 157 respectively
Create a delivery for customer 1000000 (entry exists in Ztable) and plant 1410 (entry doesn’t exist in Ztable for this customer)
 The incoterms and customer gr2 fields should be updated to ROU and 157 respectively
Create a SO for customer 1000018 and plant 0110 and maintain weight 600 OZ (equivalent alt UoM entry in LB exists in carrier table) for the item. Header txt indicator is not flagged then; Create a delivery for the SO
 The incoterms and cust gr2 fields should be updated per the carrier table and header text shouldn’t be deleted.

Test Cases - Change Logs



Test Scenario
 Expected Results
Copy an existing record and create a new range for the min and max weight fields and click save.
 CDHDR table should update a new record with the entered values for the min and max weight fields and system should assign a unique document no. for this record;
CDPOS table should show one record against the document no.
Copy an existing record and create a new range for the min and max weight fields and click on the back button and save at the system prompt.
 CDHDR table should update a new record with the entered values for the min and max weight fields and system should assign a unique document no. for this record;
CDPOS table should show one record against the document no.
Create a new record by inputting all values; maintain one/two wrong values in the fields and click save;
Correct the values and hit enter
 CDHDR table should update a new record for the new entry and system should assign a unique document no. for this entry;
CDPOS table should show one record against the document no.
Create a new record by inputting all the values in the fields; click back button and save at the system prompt.
 CDHDR table should update a new record for the new entry and system should assign a unique document no. for this entry;
CDPOS table should show one record against the document no.
Create multiple records by inputting all the values in the fields and check by saving in the table view and then by saving at the system prompt by clicking the back button.
 CDHDR table should update multiple records for the new entries and system should assign a unique document no.s for the entries;
CDPOS table should show multiple records against the document no.s
Change a field/s in the existing record and save.
 CDPOS table should update the changes with the changed field name/s and value/s. Record/s should be created for each change against a single document no.
Change a field/s in the existing record, click the back button and save at the system prompt.
 CDPOS table should update the changes with the changed field name/s and value/s. Record/s should be created for each change against a single document no.

Changes field/s in the existing multiple records and save.
 CDPOS table should update the changes with the changed field name/s and value/s. Record/s should be created for each change against multiple document no.s
Change a field/s in the existing multiple records, click the back button and save at the system prompt.
 CDPOS table should update the changes with the changed field name/s and value/s. Record/s should be created for each change against multiple document no.s
Delete a record and save.
 CDHDR table should update the deleted record and system should assign a unique document no. against the record;
CDPOS table should update the deleted record. One record should be created for each of the non key fields (Inco1, KVGR2,HDRTX) against a single document no.
Delete multiple records and save
 CDHDR table should update the deleted records and system should assign a unique document no.s against the records;
CDPOS table should update the deleted records. One record should be created for each of the non key fields (Inco1, KVGR2,HDRTX) against multiple document no.s
Delete a record and click the back button and save at system prompt.
 CDHDR table should update the deleted record and system should assign a unique document no. against the record;
CDPOS table should update the deleted record. One record should be created for each of the non key fields (Inco1, KVGR2,HDRTX) against a single document no.
Delete multiple records and click the back button and save at system prompt.
 CDHDR table should update the deleted records and system should assign unique document no.s against the records;
CDPOS table should update the deleted records. One record should be created for each of the non key fields (Inco1, KVGR2,HDRTX) against multiple document no.s

Test Cases - Update fields (INCO1 and KVGR2) in SOs after creation of delivery.

Scenario
 Expected Result
Create Delivery for a vendor in the table with a valid record, make sure incoterms and carrier from vendor master are different from table entries
 Delivery should be created and sales order updated with incoterms and carrier from table
Create Delivery for a vendor in the table but without a valid record
 Delivery should be created with incoterms ROU and carrier 157 (Routing); SO should not be updated.
Create Delivery for a vendor not in the table
 Delivery should be created with incoterms and carrier from the sales order; SO should not be updated.
Create Delivery for a vendor in the table with multiple valid records
 Delivery should be created and SO updated with incoterms and carrier from first record in table that matches the delivery weight
Create Delivery for a vendor in the table with a valid record, where Header text deletion indicator is set when language is EN
 Delivery should be created and SO updated with incoterms and carrier from table and delivery header text for Customer Account at Carrier, Address for Carrier (1) and Address for Carrier (2) should be deleted; SO header text should not be deleted.
Create Delivery for a vendor in the table with a valid record, where Header text deletion indicator is not set when language is EN
 Delivery should be created and SO updated with incoterms and carrier from table and delivery header text for Customer Account at Carrier, Address for Carrier (1) and Address for Carrier (2) should be carried over from Sales Order / Customer Text; SO header text should not be deleted.
Create a delivery with UOM in Kg and table entry in lbs.
 Conversion should work correctly, choosing the correct weight range table entry
Create a delivery with UOM in oz. and table entry in lbs.
 Conversion should work correctly, choosing the correct weight range table entry
Create a delivery with UOM in TON and table entry in Kg.
 Conversion should work correctly, choosing the correct weight range table entry
Create a delivery with a weight of 100 lbs when there are records for 0 - 100 and 100 - 999999
 Delivery should be created with the incoterms and carrier from the 0 - 100 record
Create a delivery with weight of 101 lbs when there are records for 0 - 100 and 100 - 999999
 Delivery should be created with the incoterms and carrier from the 100 - 500 record
Create deliveries via batch to make sure they create correctly
 Deliveries should be created via a batch job with the correct incoterms and carrier based on the table entries and SO's should be updated accordingly.
Create Delivery for a vendor in the table with a valid record, where Header text deletion indicator is set when language is not EN
 Delivery should be created and SO updated with incoterms and carrier from table and delivery header text for Customer Account at Carrier, Address for Carrier (1) and Address for Carrier (2) is deleted; SO header text should not be deleted.
Create Delivery for a vendor in the table with a valid record, where Header text deletion indicator is not set when language is not EN
 Delivery should be created and SO updated with incoterms and carrier from table and delivery header text for Customer Account at Carrier, Address for Carrier (1) and Address for Carrier (2) is carried over from Sales Order / Customer Text; SO header text should not be deleted.
Create Delivery for a vendor in the table with a valid record but outside the weight range
 Delivery should be created and SO updated with incoterms ROU and carrier 157 (Routing); SO header text should not be deleted.
Create a delivery with a weight of 100 lbs when there are records for 0 - 100 and 100 – 999999(both in KG and LB)
0-100—KG and 0-100- LB records are maintained in the table.
 Delivery should be created and SO updated with incoterms and the Customer group 2 of the first matching entry from the table.

Solution Details

Provide complete technical details for configuration or programming here.

Created new Z table, ZSDT_CARR_DETR to maintain records for carrier determination in the delivery and generated table maintenance.
Below are the fields in the table
KUNAG
 Sold-to party
VSTEL
 Shipping Point/Receiving Point
GEWEI
 Weight Unit
MNGEW
 Minimum weight
MXGEW
 Maximum weight
INCO1
 Incoterms (Part 1)
BEZEI
 Incoterms name
KVGR2
 Customer group 2
CUST_GROUP2
 Customer group 2 Description
HDRTX
 Delete Account Header Text Indicator

1. Created Tcode ZSD_CARRIER and assigned to the table ZSDT_CARR_DETR.
2. Created custom F1 help for Min (MNGEW) and Max (MXGEW) weight fields in maintenance view.
3. Enhanced Delivery user exit ( MV50AFZ1 ) to update Customer group2 (KVGR2) and Incoterms (INCO1) values.
3. Created new FM ZSD_DELIVERY_DEL_TEXT to delete header text fields (HDRTX), Address for carrier(1) , Address for carrier(2) if header deletion indicator is marked for customer.
4. Acivated change logs option in the table to track creation/updation/deletion of records in the table by creating Change Document object ZCARRIER in the table. Logs can be viewed in the standard tables CDHDR and CDPOS by using the custom object, ZCARRIER.
5. Enhanced Delivery user exit to update SO fields (INCO1 & KVGR2) through standard BAPI (BAPI_Salesorder_Change) for the given criteria.



Issues

The below mentioned bugs/issues were fixed-
1. "Sold to" field should be considered as the entry in the table when there are no matching records.
2. Header text deletion when flagged should look for the correct entry when alternative UoM is maintained in the table (i.e, different from the UoM in the delivery).
3. Incorterms and Customer Gr2 field should default to ROU and 157 respectively when there are no matching records but an entry exists in the table.
4. Corrections/changes were made to the table to meet the specified requirements.